home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1423.txt < prev    next >
Text File  |  1994-08-01  |  33KB  |  787 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        D. Balenson
  8. Request for Comments: 1423                                           TIS
  9. Obsoletes: 1115                               IAB IRTF PSRG, IETF PEM WG
  10.                                                            February 1993
  11.  
  12.  
  13.            Privacy Enhancement for Internet Electronic Mail:
  14.               Part III: Algorithms, Modes, and Identifiers
  15.  
  16. Status of This Memo
  17.  
  18.    This RFC specifies an IAB standards track protocol for the Internet
  19.    community, and requests discussion and suggestions for improvements.
  20.    Please refer to the current edition of the "IAB Official Protocol
  21.    Standards" for the standardization state and status of this protocol.
  22.    Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    This document provides definitions, formats, references, and
  27.    citations for cryptographic algorithms, usage modes, and associated
  28.    identifiers and parameters used in support of Privacy Enhanced Mail
  29.    (PEM) in the Internet community.  It is intended to become one member
  30.    of the set of related PEM RFCs.  This document is organized into four
  31.    primary sections, dealing with message encryption algorithms, message
  32.    integrity check algorithms, symmetric key management algorithms, and
  33.    asymmetric key management algorithms (including both asymmetric
  34.    encryption and asymmetric signature algorithms).
  35.  
  36.    Some parts of this material are cited by other documents and it is
  37.    anticipated that some of the material herein may be changed, added,
  38.    or replaced without affecting the citing documents.  Therefore,
  39.    algorithm-specific material has been placed into this separate
  40.    document.
  41.  
  42.    Use of other algorithms and/or modes will require case-by-case study
  43.    to determine applicability and constraints.  The use of additional
  44.    algorithms may be documented first in Prototype or Experimental RFCs.
  45.    As experience is gained, these protocols may be considered for
  46.    incorporation into the standard.  Additional algorithms and modes
  47.    approved for use in PEM in this context will be specified in
  48.    successors to this document.
  49.  
  50. Acknowledgments
  51.  
  52.    This specification was initially developed by the Internet Research
  53.    Task Force's Privacy and Security Research Group (IRTF PSRG) and
  54.    subsequently refined based on discussion in the Internet Engineering
  55.  
  56.  
  57.  
  58. Balenson                                                        [Page 1]
  59.  
  60. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  61.  
  62.  
  63.    Task Force's Privacy Enhanced Mail Working Group (IETF PEM WG).  John
  64.    Linn contributed significantly to the predecessor of this document
  65.    (RFC 1115).  I would like to thank the members of the PSRG and PEM
  66.    WG, as well as all participants in discussions on the "pem-
  67.    dev@tis.com" mailing list, for their contributions to this document.
  68.  
  69. Table of Contents
  70.  
  71.       1.  Message Encryption Algorithms ....................... 2
  72.       1.1  DES in CBC Mode (DES-CBC) .......................... 2
  73.       2.  Message Integrity Check Algorithms .................. 4
  74.       2.1  RSA-MD2 Message Digest Algorithm ................... 4
  75.       2.2  RSA-MD5 Message Digest Algorithm ................... 5
  76.       3.  Symmetric Key Management Algorithms ................. 6
  77.       3.1  DES in ECB mode (DES-ECB) .......................... 6
  78.       3.2  DES in EDE mode (DES-EDE) .......................... 7
  79.       4.  Asymmetric Key Management Algorithms ................ 7
  80.       4.1  Asymmetric Keys .................................... 7
  81.       4.1.1  RSA Keys ......................................... 7
  82.       4.2  Asymmetric Encryption Algorithms ..................  9
  83.       4.2.1  RSAEncryption ...................................  9
  84.       4.3  Asymmetric Signature Algorithms ................... 10
  85.       4.3.1  md2WithRSAEncryption ............................ 11
  86.       5.  Descriptive Grammar ................................ 11
  87.       References ............................................. 12
  88.       Patent Statement ....................................... 13
  89.       Security Considerations ................................ 14
  90.       Author's Address ....................................... 14
  91.  
  92. 1.  Message Encryption Algorithms
  93.  
  94.    This section identifies the alternative message encryption algorithms
  95.    and modes that shall be used to encrypt message text and, when
  96.    asymmetric key management is employed in an ENCRYPTED PEM message, for
  97.    encryption of message signatures.  Character string identifiers are
  98.    assigned and any parameters required by the message encryption
  99.    algorithm are defined for incorporation in an encapsulated "DEK-
  100.    Info:" header field.
  101.  
  102.    Only one alternative is currently defined in this category.
  103.  
  104. 1.1  DES in CBC Mode (DES-CBC)
  105.  
  106.    Message text and, if required, message signatures are encrypted using
  107.    the Data Encryption Standard (DES) algorithm in the Cipher Block
  108.    Chaining (CBC) mode of operation.  The DES algorithm is defined in
  109.    FIPS PUB 46-1 [1], and is equivalent to the Data Encryption Algorithm
  110.    (DEA) provided in ANSI X3.92-1981 [2].  The CBC mode of operation of
  111.  
  112.  
  113.  
  114. Balenson                                                        [Page 2]
  115.  
  116. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  117.  
  118.  
  119.    DES is defined in FIPS PUB 81 [3], and is equivalent to those
  120.    provided in ANSI X3.106 [4] and in ISO IS 8372 [5].  The character
  121.    string "DES-CBC" within an encapsulated PEM header field indicates
  122.    the use of this algorithm/mode combination.
  123.  
  124.    The input to the DES CBC encryption process shall be padded to a
  125.    multiple of 8 octets, in the following manner.  Let n be the length
  126.    in octets of the input.  Pad the input by appending 8-(n mod 8)
  127.    octets to the end of the message, each having the value 8-(n mod 8),
  128.    the number of octets being added.  In hexadecimal, the possible
  129.    paddings are:  01, 0202, 030303, 04040404, 0505050505, 060606060606,
  130.    07070707070707, and 0808080808080808.  All input is padded with 1 to
  131.    8 octets to produce a multiple of 8 octets in length.  The padding
  132.    can be removed unambiguously after decryption.
  133.  
  134.    The DES CBC encryption process requires a 64-bit cryptographic key.
  135.    A new, pseudorandom key shall be generated for each ENCRYPTED PEM
  136.    message.  Of the 64 bits, 56 are used directly by the DES CBC
  137.    process, and 8 are odd parity bits, with one parity bit occupying the
  138.    right-most bit of each octet.  When symmetric key management is
  139.    employed, the setting and checking of odd parity bits is encouraged,
  140.    since these bits could detect an error in the decryption of a DES key
  141.    encrypted under a symmetric key management algorithm (e.g., DES ECB).
  142.    When asymmetric key management is employed, the setting of odd parity
  143.    bits is encouraged, but the checking of odd parity bits is
  144.    discouraged, in order to facilitate interoperability, and since an
  145.    error in the decryption of a DES key can be detected by other means
  146.    (e.g., an incorrect PKCS #1 encryption-block format).  In all cases,
  147.    the encrypted form of a DES key shall carry all 64 bits of the key,
  148.    including the 8 parity bits, though those bits may have no meaning.
  149.  
  150.    The DES CBC encryption process also requires a 64-bit Initialization
  151.    Vector (IV).  A new, pseudorandom IV shall be generated for each
  152.    ENCRYPTED PEM message.  Section 4.3.1 of [7] provides rationale for
  153.    this requirement, even given the fact that individual DES keys are
  154.    generated for individual messages.  The IV is transmitted with the
  155.    message within an encapsulated PEM header field.
  156.  
  157.    When this algorithm/mode combination is used for message text
  158.    encryption, the "DEK-Info:" header field carries exactly two
  159.    arguments.  The first argument identifies the DES CBC algorithm/mode
  160.    using the character string defined above.  The second argument
  161.    contains the IV, represented as a contiguous string of 16 ASCII
  162.    hexadecimal digits.
  163.  
  164.    When symmetric key management is employed with this algorithm/mode
  165.    combination, a symmetrically encrypted DES key will be represented in
  166.    the third argument of a "Key-Info:" header field as a contiguous
  167.  
  168.  
  169.  
  170. Balenson                                                        [Page 3]
  171.  
  172. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  173.  
  174.  
  175.    string of 16 ASCII hexadecimal digits (corresponding to a 64-bit
  176.    key).
  177.  
  178.    To avoid any potential ambiguity regarding the ordering of the octets
  179.    of a DES key that is input as a data value to another encryption
  180.    process (e.g., RSAEncryption), the following holds true.  The first
  181.    (or left-most displayed, if one thinks in terms of a key's "print"
  182.    representation) (For purposes of discussion in this document, data
  183.    values are normalized in terms of their "print" representation.  For a
  184.    octet stream, the "first" octet would appear as the one on the "left",
  185.    and the "last" octet would appear on the "right".) octet of the key
  186.    (i.e., bits 1-8 per FIPS PUB 46-1), when considered as a data value,
  187.    has numerical weight 2**56.  The last (or right-most displayed) octet
  188.    (i.e., bits 57-64 per FIPS PUB 46-1) has numerical weight 2**0.
  189.  
  190. 2.  Message Integrity Check Algorithms
  191.  
  192.    This section identifies the alternative algorithms that shall be used
  193.    to compute Message Integrity Check (MIC) values for PEM messages.
  194.    Character string identifiers and ASN.1 object identifiers are
  195.    assigned for incorporation in encapsulated "MIC-Info:" and "Key-
  196.    Info:" header fields to indicate the choice of MIC algorithm
  197.    employed.
  198.  
  199.    A compliant PEM implementation shall be able to process all of the
  200.    alternative MIC algorithms defined here on incoming messages.  It is
  201.    a sender option as to which alternative is employed on an outbound
  202.    message.
  203.  
  204. 2.1  RSA-MD2 Message Digest Algorithm
  205.  
  206.    The RSA-MD2 message digest is computed using the algorithm defined in
  207.    RFC 1319 [9].  ( An error has been identified in RFC 1319.  The
  208.    statement in the text of Section 3.2 which reads "Set C[j] to S[c xor
  209.    L]" should read "Set C[j] to S[c xor L] xor C[j]".  Note that the C
  210.    source code in the appendix of RFC 1319 is correct.)  The character
  211.    string "RSA-MD2" within an encapsulated PEM header field indicates the
  212.    use of this algorithm.  Also, as defined in RFC 1319, the ASN.1 object
  213.    identifier
  214.  
  215.      md2 OBJECT IDENTIFIER ::= {
  216.          iso(1) member-body(2) US(840) rsadsi(113549)
  217.          digestAlgorithm(2) 2
  218.      }
  219.  
  220.    identifies this algorithm.  When this object identifier is used with
  221.    the ASN.1 type AlgorithmIdentifier, the parameters component of that
  222.    type is the ASN.1 type NULL.
  223.  
  224.  
  225.  
  226. Balenson                                                        [Page 4]
  227.  
  228. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  229.  
  230.  
  231.    The RSA-MD2 message digest algorithm accepts as input a message of
  232.    any length and produces as output a 16-octet quantity.  When
  233.    symmetric key management is employed, an RSA-MD2 MIC is encrypted by
  234.    splitting the MIC into two 8-octet halves, independently encrypting
  235.    each half, and concatenating the results.
  236.  
  237.    When symmetric key management is employed with this MIC algorithm,
  238.    the symmetrically encrypted MD2 message digest is represented in a
  239.    the fourth argument of a "Key-Info:" header field as a contiguous
  240.    string of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD2
  241.    message digest).
  242.  
  243.    To avoid any potential ambiguity regarding the ordering of the octets
  244.    of an MD2 message digest that is input as a data value to another
  245.    encryption process (e.g., RSAEncryption), the following holds true.
  246.    The first (or left-most displayed, if one thinks in terms of a
  247.    digest's "print" representation) octet of the digest (i.e., digest[0]
  248.    as specified in RFC 1319), when considered as an RSA data value, has
  249.    numerical weight 2**120.  The last (or right-most displayed) octet
  250.    (i.e., digest[15] as specified in RFC 1319) has numerical weight
  251.    2**0.
  252.  
  253. 2.2  RSA-MD5 Message Digest Algorithm
  254.  
  255.    The RSA-MD5 message digest is computed using the algorithm defined in
  256.    RFC 1321 [10].  The character string "RSA-MD5" within an encapsulated
  257.    PEM header field indicates the use of this algorithm.  Also, as
  258.    defined in RFC 1321, the object identifier
  259.  
  260.      md5 OBJECT IDENTIFIER ::= {
  261.          iso(1) member-body(2) US(840) rsadsi(113549)
  262.          digestAlgorithm(2) 5
  263.      }
  264.  
  265.    identifies this algorithm.  When this object identifier is used with
  266.    the ASN.1 type AlgorithmIdentifier, the parameters component of that
  267.    type is the ASN.1 type NULL.
  268.  
  269.    The RSA-MD5 message digest algorithm accepts as input a message of
  270.    any length and produces as output a 16-octet quantity.  When
  271.    symmetric key management is employed, an RSA-MD5 MIC is encrypted by
  272.    splitting the MIC into two 8-octet halves, independently encrypting
  273.    each half, and concatenating the results.
  274.  
  275.    When symmetric key management is employed with this MIC algorithm,
  276.    the symmetrically encrypted MD5 message digest is represented in the
  277.    fourth argument of a "Key-Info:" header field as a contiguous string
  278.    of 32 ASCII hexadecimal digits (corresponding to a 128-bit MD5
  279.  
  280.  
  281.  
  282. Balenson                                                        [Page 5]
  283.  
  284. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  285.  
  286.  
  287.    message digest).
  288.  
  289.    To avoid any potential ambiguity regarding the ordering of the octets
  290.    of a MD5 message digest that is input as an RSA data value to the RSA
  291.    encryption process, the following holds true.  The first (or left-
  292.    most displayed, if one thinks in terms of a digest's "print"
  293.    representation) octet of the digest (i.e., the low-order octet of A
  294.    as specified in RFC 1321), when considered as an RSA data value, has
  295.    numerical weight 2**120.  The last (or right-most displayed) octet
  296.    (i.e., the high-order octet of D as specified in RFC 1321) has
  297.    numerical weight 2**0.
  298.  
  299. 3.  Symmetric Key Management Algorithms
  300.  
  301.    This section identifies the alternative algorithms and modes that
  302.    shall be used when symmetric key management is employed, to encrypt
  303.    data encryption keys (DEKs) and message integrity check (MIC) values.
  304.    Character string identifiers are assigned for incorporation in
  305.    encapsulated "Key-Info:" header fields to indicate the choice of
  306.    algorithm employed.
  307.  
  308.    All alternatives presently defined in this category correspond to
  309.    different usage modes of the DES algorithm, rather than to other
  310.    algorithms.
  311.  
  312.    When symmetric key management is employed, the symmetrically
  313.    encrypted DEK and MIC, carried in the third and fourth arguments of a
  314.    "Key-Info:" header field, respectively, are each represented as a
  315.    string of contiguous ASCII hexadecimal digits.  The manner in which
  316.    to use the following symmetric encryption algorithms and the length
  317.    of the symmetrically encrypted DEK and MIC may vary depending on the
  318.    length of the underlying DEK and MIC.  Section 1, Message Encryption
  319.    Algorithms, and Section 2, Message Integrity Check Algorithms,
  320.    provide information on the proper manner in which a DEK and MIC,
  321.    respectively, are symmetrically encrypted when the size of the DEK or
  322.    MIC is not equal to the symmetric encryption algorithm's input block
  323.    size.  These sections also provide information on the proper format
  324.    and length of the symmetrically encrypted DEK and MIC, respectively.
  325.  
  326. 3.1  DES in ECB Mode (DES-ECB)
  327.  
  328.    The DES algorithm in Electronic Codebook (ECB) mode [1][3] is used
  329.    for DEK and MIC encryption when symmetric key management is employed.
  330.    The character string "DES-ECB" within an encapsulated PEM header
  331.    field indicates use of this algorithm/mode combination.
  332.  
  333.    A compliant PEM implementation supporting symmetric key management
  334.    shall support this algorithm/mode combination.
  335.  
  336.  
  337.  
  338. Balenson                                                        [Page 6]
  339.  
  340. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  341.  
  342.  
  343. 3.2  DES in EDE Mode (DES-EDE)
  344.  
  345.    The DES algorithm in Encrypt-Decrypt-Encrypt (EDE) multiple
  346.    encryption mode, as defined by ANSI X9.17 [6] for encryption and
  347.    decryption with pairs of 64-bit keys, may be used for DEK and MIC
  348.    encryption when symmetric key management is employed.  The character
  349.    string "DES-EDE" within an encapsulated a PEM header field indicates
  350.    use of this algorithm/mode combination.
  351.  
  352.    A compliant PEM implementation supporting symmetric key management
  353.    may optionally support this algorithm/mode combination.
  354.  
  355. 4.  Asymmetric Key Management Algorithms
  356.  
  357.    This section identifies the alternative asymmetric keys and the
  358.    alternative asymmetric key management algorithms with which those
  359.    keys shall be used, namely the asymmetric encryption algorithms with
  360.    which DEKs and MICs are encrypted, and the asymmetric signature
  361.    algorithms with which certificates and certificate revocation lists
  362.    (CRLs) are signed.
  363.  
  364. 4.1  Asymmetric Keys
  365.  
  366.    This section describes the asymmetric keys that shall be used with
  367.    the asymmetric encryption algorithms and the signature algorithms
  368.    described later.  ASN.1 object identifiers are identified for
  369.    incorporation in a public-key certificate to identify the
  370.    algorithm(s) with which the accompanying public key is to be
  371.    employed.
  372.  
  373. 4.1.1  RSA Keys
  374.  
  375.    An RSA asymmetric key pair is comprised of matching public and
  376.    private keys.
  377.  
  378.    An RSA public key consists of an encryption exponent e and an
  379.    arithmetic modulus n, which are both public quantities typically
  380.    carried in a public-key certificate.  For the value of e, Annex C to
  381.    X.509 suggests the use of Fermat's Number F4 (65537 decimal, or
  382.    1+2**16) as a value "common to the whole environment in order to
  383.    reduce transmission capacity and complexity of transformation", i.e.,
  384.    the value can be transmitted as 3 octets and at most seventeen (17)
  385.    multiplications are required to effect exponentiation.  As an
  386.    alternative, the number three (3) can be employed as the value for e,
  387.    requiring even less octets for transmission and yielding even faster
  388.    exponentiation.  For purposes of PEM, the value of e shall be either
  389.    F4 or the number three (3).  The use of the number three (3) for the
  390.    value of e is encouraged, to permit rapid certificate validation.
  391.  
  392.  
  393.  
  394. Balenson                                                        [Page 7]
  395.  
  396. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  397.  
  398.  
  399.    An RSA private key consists of a decryption exponent d, which should
  400.    be kept secret, and the arithmetic modulus n.  Other values may be
  401.    stored with a private key to facilitate efficient private key
  402.    operations (see PKCS #1 [11]).
  403.  
  404.    For purposes of PEM, the modulus n may vary in size from 508 to 1024
  405.    bits.
  406.  
  407.    Two ASN.1 object identifiers have been defined to identify RSA public
  408.    keys.  In Annex H of X.509 [8], the object identifier
  409.  
  410.      rsa OBJECT IDENTIFIER ::= {
  411.          joint-iso-ccitt(2) ds(5) algorithm(8)
  412.          encryptionAlgorithm(1) 1
  413.      }
  414.  
  415.    is defined to identify an RSA public key.  A single parameter,
  416.    KeySize, the length of the public key modulus in bits, is defined for
  417.    use in conjunction with this object identifier.  When this object
  418.    identifier is used with the ASN.1 type AlgorithmIdentifier, the
  419.    parameters component of that type is the number of bits in the
  420.    modulus, ASN.1 encoded as an INTEGER.
  421.  
  422.    Alternatively, in PKCS #1 [11], the ASN.1 object identifier
  423.  
  424.      rsaEncryption OBJECT IDENTIFIER ::= {
  425.          iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
  426.          pkcs-1(1) 1
  427.      }
  428.  
  429.    is defined to identify both an RSA public key and the RSAEncryption
  430.    process.  There are no parameters defined in conjunction with this
  431.    object identifier, hence, when it is used with the ASN.1 type
  432.    AlgorithmIdentifier, the parameters component of that type is the
  433.    ASN.1 type NULL.
  434.  
  435.    A compliant PEM implementation may optionally generate an RSA
  436.    public-key certificate that identifies the enclosed RSA public key
  437.    (within the SubjectPublicKeyInformation component) with either the
  438.    "rsa" or the "rsaEncryption" object identifier.  Use of the "rsa"
  439.    object identifier is encouraged, since it is, in some sense, more
  440.    generic in its identification of a key, without indicating how the
  441.    key will be used.  However, to facilitate interoperability, a
  442.    compliant PEM implementation shall accept RSA public-key certificates
  443.    that identify the enclosed RSA public key with either the "rsa" or
  444.    the "rsaEncryption" object identifier.  In all cases, an RSA public
  445.    key identified in an RSA public-key certificate with either the "rsa"
  446.    or "rsaEncryption" object identifier, shall be used according to the
  447.  
  448.  
  449.  
  450. Balenson                                                        [Page 8]
  451.  
  452. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  453.  
  454.  
  455.    procedures defined below for asymmetric encryption algorithms and
  456.    asymmetric signature algorithms.
  457.  
  458. 4.2  Asymmetric Encryption Algorithms
  459.  
  460.    This section identifies the alternative algorithms that shall be used
  461.    when asymmetric key management is employed, to encrypt DEKs and MICs.
  462.    Character string identifiers are assigned for incorporation in "MIC-
  463.    Info:" and "Key-Info:" header fields to indicate the choice of
  464.    algorithm employed.
  465.  
  466.    Only one alternative is presently defined in this category.
  467.  
  468. 4.2.1  RSAEncryption
  469.  
  470.    The RSAEncryption public-key encryption algorithm, defined in PKCS #1
  471.    [11], is used for DEK and MIC encryption when asymmetric key
  472.    management is employed.  The character string "RSA" within a "MIC-
  473.    Info:" or "Key-Info:" header field indicates the use of this
  474.    algorithm.
  475.  
  476.    All PEM implementations supporting asymmetric key management shall
  477.    support this algorithm.
  478.  
  479.    As described in PKCS #1, all quantities input as data values to the
  480.    RSAEncryption process shall be properly justified and padded to the
  481.    length of the modulus prior to the encryption process.  In general,
  482.    an RSAEncryption input value is formed by concatenating a leading
  483.    NULL octet, a block type BT, a padding string PS, a NULL octet, and
  484.    the data quantity D, that is,
  485.  
  486.      RSA input value = 0x00 || BT || PS || 0x00 || D.
  487.  
  488.    To prepare a DEK for RSAEncryption, the PKCS #1 "block type 02"
  489.    encryption-block formatting scheme is employed.  The block type BT is
  490.    a single octet containing the value 0x02 and the padding string PS is
  491.    one or more octets (enough octets to make the length of the complete
  492.    RSA input value equal to the length of the modulus) each containing a
  493.    pseudorandomly generated, non-zero value.  For multiple recipient
  494.    messages, a different, pseudorandom padding string should be used for
  495.    each recipient.  The data quantity D is the DEK itself, which is
  496.    right-justified within the RSA input such that the last (or rightmost
  497.    displayed, if one thinks in terms of the "print" representation)
  498.    octet of the DEK is aligned with the right-most, or least-
  499.    significant, octet of the RSA input.  Proceeding to the left, each of
  500.    the remaining octets of the DEK, up through the first (or left-most
  501.    displayed) octet, are each aligned in the next more significant octet
  502.    of the RSA input.
  503.  
  504.  
  505.  
  506. Balenson                                                        [Page 9]
  507.  
  508. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  509.  
  510.  
  511.    To prepare a MIC for RSAEncryption, the PKCS #1 "block type 01"
  512.    encryption-block formatting scheme is employed.  The block type BT is
  513.    a single octet containing the value 0x01 and the padding string PS is
  514.    one or more octets (enough octets to make the length of the complete
  515.    RSA input value equal to the length of the modulus) each containing
  516.    the value 0xFF.  The data quantity D is comprised of the MIC and the
  517.    MIC algorithm identifier which are ASN.1 encoded as the following
  518.    sequence.
  519.  
  520.      SEQUENCE {
  521.          digestAlgorithm   AlgorithmIdentifier,
  522.          digest            OCTET STRING
  523.      }
  524.  
  525.    The ASN.1 type AlgorithmIdentifier is defined in X.509 as follows.
  526.  
  527.      AlgorithmIdentifier ::= SEQUENCE {
  528.          algorithm         OBJECT IDENTIFIER,
  529.          parameters        ANY DEFINED BY algorithm OPTIONAL
  530.      }
  531.  
  532.    An RSA input block is encrypted using the RSA algorithm with the
  533.    first (or left-most) octet taken as the most significant octet, and
  534.    the last (or right-most) octet taken as the least significant octet.
  535.    The resulting RSA output block is interpreted in a similar manner.
  536.  
  537.    When RSAEncryption is used to encrypt a DEK, the second argument in a
  538.    "MIC-Info:" header field, an asymmetrically encrypted DEK, is
  539.    represented using the printable encoding technique defined in Section
  540.    4.3.2.4 of RFC 1421 [12].
  541.  
  542.    When RSAEncryption is used to sign a MIC, the third argument in a
  543.    "MIC-Info:" header field, an asymmetrically signed MIC, is
  544.    represented using the printable encoding technique defined in Section
  545.    4.3.2.4 of RFC 1421.
  546.  
  547. 4.3  Asymmetric Signature Algorithms
  548.  
  549.    This section identifies the alternative algorithms which shall be
  550.    used to asymmetrically sign certificates and certificate revocation
  551.    lists (CRLs) in accordance with the SIGNED macro defined in Annex G
  552.    of X.509.  ASN.1 object identifiers are identified for incorporation
  553.    in certificates and CRLs to indicate the choice of algorithm
  554.    employed.
  555.  
  556.    Only one alternative is presently defined in this category.
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Balenson                                                       [Page 10]
  563.  
  564. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  565.  
  566.  
  567. 4.3.1  md2WithRSAEncryption
  568.  
  569.    The md2WithRSAEncryption signature algorithm is used to sign
  570.    certificates and CRLs.  The algorithm is defined in PKCS #1 [11].  It
  571.    combines the RSA-MD2 message digest algorithm described here in
  572.    Section 2.2 with the RSAEncryption asymmetric encryption algorithm
  573.    described here in Section 4.2.1.  As defined in PKCS #1, the ASN.1
  574.    object identifier
  575.  
  576.      md2WithRSAEncryption OBJECT IDENTIFIER ::= {
  577.          iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
  578.          pkcs-1(1) 2
  579.      }
  580.  
  581.    identifies this algorithm.  When this object identifier is used with
  582.    the ASN.1 type AlgorithmIdentifier, the parameters component of that
  583.    type is the ASN.1 type NULL.
  584.  
  585.    There is some ambiguity in X.509 regarding the definition of the
  586.    SIGNED macro and, in particular, the representation of a signature in
  587.    a certificate or a CRL.  The interpretation selected for PEM requires
  588.    that the data to be signed (in our case, an MD2 message digest) is
  589.    first ASN.1 encoded as an OCTET STRING and the result is encrypted
  590.    (in our case, using RSAEncryption) to form the signed quantity, which
  591.    is then ASN.1 encoded as a BIT STRING.
  592.  
  593. 5.  Descriptive Grammar
  594.  
  595.    ; Addendum to PEM BNF representation, using RFC 822 notation
  596.    ; Provides specification for official PEM cryptographic algorithms,
  597.    ; modes, identifiers and formats.
  598.  
  599.    ; Imports <hexchar> and <encbin> from RFC [1421]
  600.  
  601.        <dekalgid> ::= "DES-CBC"
  602.        <ikalgid>  ::= "DES-EDE" / "DES-ECB" / "RSA"
  603.        <sigalgid> ::= "RSA"
  604.        <micalgid> ::= "RSA-MD2" / "RSA-MD5"
  605.  
  606.        <dekparameters> ::= <DESCBCparameters>
  607.        <DESCBCparameters> ::= <IV>
  608.        <IV> ::= <hexchar16>
  609.  
  610.        <symencdek> ::= <DESECBencDESCBC> / <DESEDEencDESCBC>
  611.        <DESECBencDESCBC> ::= <hexchar16>
  612.        <DESEDEencDESCBC> ::= <hexchar16>
  613.  
  614.        <symencmic> ::= <DESECBencRSAMD2> / <DESECBencRSAMD5>
  615.  
  616.  
  617.  
  618. Balenson                                                       [Page 11]
  619.  
  620. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  621.  
  622.  
  623.        <DESECBencRSAMD2> ::= 2*2<hexchar16>
  624.        <DESECBencRSAMD5> ::= 2*2<hexchar16>
  625.  
  626.        <asymsignmic> ::= <RSAsignmic>
  627.        <RSAsignmic> ::= <encbin>
  628.  
  629.        <asymencdek> ::= <RSAencdek>
  630.        <RSAencdek> ::= <encbin>
  631.  
  632.        <hexchar16> ::= 16*16<hexchar>
  633.  
  634. References
  635.  
  636.    [1] Federal Information Processing Standards Publication (FIPS PUB)
  637.        46-1, Data Encryption Standard, Reaffirmed 1988 January 22
  638.        (supersedes FIPS PUB 46, 1977 January 15).
  639.  
  640.    [2] ANSI X3.92-1981, American National Standard Data Encryption
  641.        Algorithm, American National Standards Institute, Approved 30
  642.        December 1980.
  643.  
  644.    [3] Federal Information Processing Standards Publication (FIPS PUB)
  645.        81, DES Modes of Operation, 1980 December 2.
  646.  
  647.    [4] ANSI X3.106-1983, American National Standard for Information
  648.        Systems - Data Encryption Algorithm - Modes of Operation,
  649.        American National Standards Institute, Approved 16 May 1983.
  650.  
  651.    [5] ISO 8372, Information Processing Systems: Data Encipherment:
  652.        Modes of Operation of a 64-bit Block Cipher.
  653.  
  654.    [6] ANSI X9.17-1985, American National Standard, Financial
  655.        Institution Key Management (Wholesale), American Bankers
  656.        Association, April 4, 1985, Section 7.2.
  657.  
  658.    [7] Voydock, V. L. and Kent, S. T., "Security Mechanisms in High-
  659.        Level Network Protocols", ACM Computing Surveys, Vol. 15, No. 2,
  660.        June 1983, pp. 135-171.
  661.  
  662.    [8] CCITT Recommendation X.509, "The Directory - Authentication
  663.        Framework", November 1988, (Developed in collaboration, and
  664.        technically aligned, with ISO 9594-8).
  665.  
  666.    [9] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, RSA
  667.        Laboratories, April 1992.
  668.  
  669.   [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, MIT
  670.        Laboratory for Computer Science and RSA Data Security, Inc.,
  671.  
  672.  
  673.  
  674. Balenson                                                       [Page 12]
  675.  
  676. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  677.  
  678.  
  679.        April 1992.
  680.  
  681.   [11] PKCS #1: RSA Encryption Standard, Version 1.4, RSA Data Security,
  682.        Inc., June 3, 1991.
  683.  
  684.   [12] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
  685.        I: Message Encryption and Authentication Procedures", RFC 1421,
  686.        DEC, February 1993.
  687.  
  688.   [13] Kent, S., "Privacy Enhancement for Internet Electronic Mail: Part
  689.        II: Certificate-Based Key Management", RFC 1422, BBN, February
  690.        1993.
  691.  
  692.   [14] Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
  693.        Part IV: Key Certification and Related Services", RFC 1424, RSA
  694.        Laboratories, February 1993.
  695.  
  696. Patent Statement
  697.  
  698.    This version of Privacy Enhanced Mail (PEM) relies on the use of
  699.    patented public key encryption technology for authentication and
  700.    encryption.  The Internet Standards Process as defined in RFC 1310
  701.    requires a written statement from the Patent holder that a license
  702.    will be made available to applicants under reasonable terms and
  703.    conditions prior to approving a specification as a Proposed, Draft or
  704.    Internet Standard.
  705.  
  706.    The Massachusetts Institute of Technology and the Board of Trustees
  707.    of the Leland Stanford Junior University have granted Public Key
  708.    Partners (PKP) exclusive sub-licensing rights to the following
  709.    patents issued in the United States, and all of their corresponding
  710.    foreign patents:
  711.  
  712.       Cryptographic Apparatus and Method
  713.       ("Diffie-Hellman")............................... No. 4,200,770
  714.  
  715.       Public Key Cryptographic Apparatus
  716.       and Method ("Hellman-Merkle").................... No. 4,218,582
  717.  
  718.       Cryptographic Communications System and
  719.       Method ("RSA")................................... No. 4,405,829
  720.  
  721.       Exponential Cryptographic Apparatus
  722.       and Method ("Hellman-Pohlig").................... No. 4,424,414
  723.  
  724.    These patents are stated by PKP to cover all known methods of
  725.    practicing the art of Public Key encryption, including the variations
  726.    collectively known as El Gamal.
  727.  
  728.  
  729.  
  730. Balenson                                                       [Page 13]
  731.  
  732. RFC 1423         PEM: Algorithms, Modes and Identifiers    February 1993
  733.  
  734.  
  735.    Public Key Partners has provided written assurance to the Internet
  736.    Society that parties will be able to obtain, under reasonable,
  737.    nondiscriminatory terms, the right to use the technology covered by
  738.    these patents.  This assurance is documented in RFC 1170 titled
  739.    "Public Key Standards and Licenses".  A copy of the written assurance
  740.    dated April 20, 1990, may be obtained from the Internet Assigned
  741.    Number Authority (IANA).
  742.  
  743.    The Internet Society, Internet Architecture Board, Internet
  744.    Engineering Steering Group and the Corporation for National Research
  745.    Initiatives take no position on the validity or scope of the patents
  746.    and patent applications, nor on the appropriateness of the terms of
  747.    the assurance.  The Internet Society and other groups mentioned above
  748.    have not made any determination as to any other intellectual property
  749.    rights which may apply to the practice of this standard. Any further
  750.    consideration of these matters is the user's own responsibility.
  751.  
  752. Security Considerations
  753.  
  754.    This entire document is about security.
  755.  
  756. Author's Address
  757.  
  758.    David Balenson
  759.    Trusted Information Systems
  760.    3060 Washington Road
  761.    Glenwood, Maryland 21738
  762.  
  763.    Phone: 301-854-6889
  764.    EMail: balenson@tis.com
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Balenson                                                       [Page 14]
  787.